- This was one of my primary arguments in 62.15 Project Management Peace, a training I created to help people build their own software-agnostic project management system. I created it because I realized that when someone would ask (e.g, in Facebook groups) about the best “project management systems”, everyone was recommending software. I know that’s probably what they meant — they were likely hoping for software recommendations. But equating software and systems, I think, is why so many people struggle with shiny software syndrome and find themselves switching between tools over and over again.
- Because software isn’t a system. Software is a tool that holds your system and shows it to you in a way that, ideally, makes it easier to work within your system.
- For example, ClickUp is not a project management system. It’s a wrapper for your projects. It’s an asset that can help you do things like automate due dates, create templates for your projects, and connect documents to your tasks. But it is not, on its own, a system. ClickUp does not manage your projects, it just shows you the projects that need managing.
- Meanwhile, if you’re using, say, Asana and are struggling to meet your deadlines, putting the same projects with the same deadlines into ClickUp isn’t going to fix the problem. If you’re having a hard time breaking projects into tasks, there aren’t any features of ClickUp that will change how you are doing that. If the bottleneck is that you just have too much on your plate, migrating your workload isn’t going to alleviate the pressure.
- If your system is a mess, moving it to a different tool isn’t going to clean it up. Because you build the system, the software just makes it look nice.
- This line of thinking goes for all software, in my opinion. Google Calendar is not a calendar management system, but a tool to help manage your calendar; Zapier is not an automation system, but a tool to help you build automations; Obsidian is not a knowledge management system, but a tool that holds it. So on and so on.
- I think this is such an important concept because I see it as a cornerstone of productivity. You have to build and iterate your system before you find a software that can be an asset in actually using it. This is similar to the idea that you should {3.4} build systems by working manually, organizing patterns, and mechanizing them (in that order).